Pike is normally pretty stable, but should you find yourself in a situation where pike is crashing (especially when running a development snapshot), the following information might be helpful.

__Run pike under GDB__

{code}
gdb /path/to/pike
gdb> set args -arg1 val1 program.pike
gdb> run
{code}

Pike should start and run; when it hits a point where it crashes, you'll be returned to the gdb prompt.

If you have the broken pike running in a gdb, you can try running

{code}
call gdb_backtraces()
{code}

as well as

{code}
thread apply all bt
{code}

The latter should also work when examining a core dump.

If it isn't possible to call gdb_backtraces(), you'll probably want to examine the stack frames by hand. The top-most frame is available as

{code}
p *Pike_interpreter_pointer->frame_pointer
{code}

Also, if you're running pike using machine code (which is the default under 7.9 on intel, sparc and powerpc platforms), you might not get useful information from the backtraces. In that case, you might have better luck running a pike that's been compiled with "--without-machine-code". If the problem goes away, it might mean a problem with the machine code generator. If not, hopefully the backtraces in gdb will make more sense.

Finally, if the bug is a sleeper whose effects show up long after the bug occurs, you might try running the program under valgrind.

Powered by PikeWiki2